SOA with .NET and Windows Azure : Windows Workflow Foundation (part 5) - WF Programming Model

Workflow Runtime Environment

A workflow instance is created and executed by the workflow runtime engine. The runtime engine relies on several runtime services for persisting the workflow’s state, managing transactions, tracking workflow’s execution, and other features. Each instance of the runtime engine can support multiple instances of a workflow concurrently. The workflow instance runs in a host process or in an application domain and can be hosted on ASP.NET Web sites, Windows forms, Windows services, Web services, or SharePoint.

The runtime engine is powered by runtime services that provide an execution environment for transactions, persistence, tracking changes, timer, and threading. Runtime services can be augmented by plugging in custom services that allow changing the behavior of the runtime engine to meet the specific needs of the execution environment.

For most workflow implementations, the default implementation of runtime services satisfies the needs of the execution; however, in some cases the behavior may need to be altered. For example, the workflow may require the host application and the runtime engine to communicate differently, which would require building custom services.

The workflow execution starts by creating an instance of the workflow. It proceeds with carrying out activities until it is required to idle the execution, at which point the instance state is persisted to disk.

WF Programming Model

WF classes are encapsulated in three namespaces, as shown in Figure 3.

Figure 4 illustrates a simple sequential workflow that contains a Calculator activity. To automate this workflow, the host will need to instantiate it and provide it with parameters including the input values and the operation to perform.

In the following example, we show this workflow hosted in a console application:

Example 1.

using System.Workflow.Runtime.Hosting;
namespace WFWorkflow
{
  class Program
  {
    static void Main(string[] args)
    {
      using(WorkflowRuntime
      workflowRuntime = new WorkflowRuntime())
      {
        AutoResetEvent
          waitHandle = new AutoResetEvent(false);
          workflowRuntime.WorkflowCompleted
            += delegate
            (object sender,
              WorkflowCompletedEventArgs e)
              {waitHandle.Set();};
          workflowRuntime.WorkflowTerminated
            += delegate
            (object sender,
              WorkflowTerminatedEventArgs e)
        }
        {
          Console.WriteLine(e.Exception.Message);
          waitHandle.Set();
        };
        WorkflowInstance instance =
          workflowRuntime.CreateWorkflow
          (typeof(WFWorkflow.CalcWorkflow));
        instance.Start();
        waitHandle.WaitOne();
      }
    }
  }
}

					  

In the preceding example, the host process initiates the workflow runtime and then starts the workflow method itself. The workflow runtime is started up by instantiating the workflowRuntime class. Passing in the workflow type to the CreateWorkflow method then creates a workflow instance class. The Start method on the workflow instance kicks off the workflow business process.

There are several events raised by the workflow runtime environment. These include WorkflowCompleted and WorkflowTerminated (the latter of which is called when there is an error). The previous example uses anonymous delegates, as WorkflowTerminatedEventArgs provides information on the exception that was generated. When the WorkflowCompleted event is called, we set the waitHandle value.